Recently, network devices that form computer networks have been adapted to enable a form of networking referred to as “software-defined networking.” In software-defined networking, the forwarding plane of a network switch, router or other network device is made available via a communication protocol such that this forwarding plane may be configured via the communication protocol rather than a routing protocol. In many implementations, the network devices may execute software to enable communications with other network devices in the network via this communication protocol so as to configure paths through the network. One example of a communication protocol that facilitates software-defined networking is the so-called “OpenFlow” communication protocol. OpenFlow is an open standard that allows users (e.g., researchers) to install software on the routers to run experimental or proprietary protocols to control packet routing or switching within a network.
The software controlled path setup may then orchestrate the configuration and deployment of paths on an as-needed basis to suit a particular service. To illustrate, orchestrating software that controls path setup may be manually configured with information identifying a network address translation (NAT) service operated by a first network device (service node). A second network device that does not provide a NAT service may communicate with the orchestrating software, learn of this NAT service and subscribe to this service, whereupon the orchestrating software may configure a path through the network from the second network device to the first network device. The second network device may then push traffic requiring NAT service through the path, where the first network device may apply the NAT traffic. When establishing the path, the orchestrating software may configure one or more filters on the second network device controlling admission of network traffic into the path. These paths having been engineered for a particular service, i.e., NAT service in this example, having filters controlling admission to the path may be referred to as “service engineered paths” (or “SEPs”). In this respect, the orchestrating software may define these SEPs to suit a particular service in terms of defining filters tailored for that service.
While SEPs may provide for service sharing and enable other network devices to forward traffic via a path that meets the needs of the service application (e.g., in terms of quality of service (QoS) provided, bandwidth, etc.), SEPs may not generally be responsive to changes in the service application. In other words, the control software managing the forwarding planes of the routers or switches along a SEP may be configured to accommodate network conditions through provisioning of paths that meet certain network requirements (e.g., in terms of bandwidth, quality of service, etc.), but may not be adapted to dynamically or automatically accommodate changes at service nodes.